FIG. 1a and FIG. 1b show a typical scenario in the prior art for providing a service to a user station UE from an application function AF, for example from a content provider. Generally, the application function AF and the user station UE cooperate through some kind of network and they exchange a request and provision message S1, S2 when the user station UE (the user equipment) requests the provision of a service or some data from the application function AF.
As shown in FIG. 1b, of course the service provided by the application function AF, typically run by an operator of the application function, will not be provided to the user station UE, more particularly to the user of the user equipment, free of charge. Therefore, typically the application function AF cooperates with a charging system CS after it receives the request message S1. The charging system CS sends an enquiry message S4 to a subscription database UDB in order to check the provision details of the service with the subscriber data. In the simplest case one can imagine that the charging system checks with the user subscription database DB whether or not the user is actually registered for receiving the service provided by the application function AF. If a positive reply message S5 is received, then the charging system CS can monitor the provision of the service and can, on behalf of the operator of the application function AF, finally charge the user of the user equipment UE with a charging message S6 whilst the service is provided with the service provision message S2 by the application function AF.
FIG. 2 shows a more concrete implementation in the framework of the 3GPP standard including the option to take the end-user's subscription data into account when constructing filters for e.g. QoS (Quality of Service) and charging only.
In FIG. 2 the application function AF is coupled through an interface Rx with the so-called Policy and Charging Rules Function (PCRF) unit which itself is coupled through an interface Sp with the subscription profile repository SPR which contains the user subscription database UDB shown in FIG. 1b. Through another interface Gx the Policy and Charging Rule Function PCRF is coupled with a gateway GW containing a Policy and Charging Enforcement Function PCEF. The gateway GW itself is coupled to an offline charging system OFCS through an interface Gz and to an online charging system OCS through an interface Gy. One could say that the Policy and Charging Rules Function PCRF unit is a kind of collection controller for collecting end-user's subscription data and for allowing the Policy and Charging Enforcement Function PCEF unit to enforce the policies and the charging when the service is actually provided from the application function AF. In corporation with the online charging system OCS and the offline charging system OFCS the Policy and Charging Enforcement Function PCEF unit “enforces”, i.e. applies the charging rules in correspondence with the subscription data retrieved from the subscription profile repository SPR. Thus, the PCED, OFCS and OCS taken together constitute a kind of charging control device.
As explained, since there is a interface Sp situated between the subscription profile repository SPR and the Policy and Charging Rules Function PCRF, the interface Sp allows the PCRF to request subscription information related to the IP-CAN transport level policies from the SPR based on a subscriber identity ID and possible IP-CAN session attributes such as IMSI, MSISDN, APN and RAT type. Furthermore, the interface Sp allows the SPR to notify the PCRF when the subscription information has been changed if the PCRF has requested such notifications.
As can be seen from FIG. 2, the 3GPP policy architecture for QoS and charging policy control allows that subscriber (user) specific subscription data influences the charging policy and the policy as to how the service is provided from the application function AF to the user equipment UE (not shown in FIG. 2). Thus, the SPR (Subscriber Policy Repository) stores subscriber related policies and data only. Examples of such data are subscription type and QoS. For example, if the agreement (see the agreement S7 in FIG. 1b) between the user and the operator of the application function AF is such that the user will be provided with a specified quality of service QoS for which he has to pay, then the PCEF enforcement unit will make sure that the service is provided with the paid for transmission quality (QoS) and that the user is charged in accordance with the charge rate applied for this user (as identified with the user identification such as IMSI, MSISDN, APN and RAT type).
In other words, the subscriber profile repository SPR, as the name indicates, is only used as a tool for subscription type and QoS data and there is no possibility that a third party, e.g. an operator of a content provider, exert any influence on the policy evaluation and the decision for new services. For example, a third party may want to offer a free service with a predetermined QoS to a selected set of users in a geographical area during a predetermined time. This may be done for service test purposes, i.e. to get an early indication whether the consumers like the service and to which price they are willing to pay for it. To put it differently, the gateway GW in the communication system, will provide the service from the application function AF to the user equipment UE (not shown in FIG. 2) in accordance with provision characteristics being charge related. However, since the provision characteristics are only user-related or user-specific there is no possibility that a third party, for example a content provider, influences the way of charging and transmission of the service—essentially because of the fact that the subscription profile repository SPR (as the name indicates) only contains subscriber-specific data.